Did you ever want to know how a video card works? Here you go, courtesy of the fine folks at X.org and the DRI project: How Video Cards Work and Radeon Architecture.

I think people are still a little euphoric over the etch release, but I'd like to let people know why Xorg 7.2 is still in experimental. Julien Cristau has done a ton of the grunt work, uploading all the usual library updates to unstable, and they're looking good so far, so at least that part is in place. The problem relates to the fact that the XSF wants to push forward with moving from Xlib to XCB. XCB represents a significant improvement over the traditional Xlib, and it's important that we work to nurture and standardize it. The good news about XCB is that most people transitioned over to it without any noticeable issues. Everything pretty much seems to work transparently, which is testament to the amount of care and time the XCB team has put in to creating it over the past several years.

But now for the bad news: there's some regressions, and they're almost all in non-free software. The biggest issue is this one: XCB will break java. You can work around it in older versions of java (as documented in that bug report) but in the newer ones you can't do much of anything. The XCB team and XSF (there's actually a fair bit of overlap there, because the XCB guys are Debian developers and I consider them XSF team members in that sense) were trying to hash out a solution to the problem. We're still working on it, but it represents the problems with depending heavily on non-free software in a free software context. Hopefully Sun will actually try to respond to the issue and release a java update that works with XCB. We can hack around the problem by disabling some checks in XCB, but the problem is really with buggy software, and we want to catch and fix those bugs. Essentially though, I'm not willing to break java in unstable so we're at something of a standstill.

In addition, there's a bug with a bit of proprietary Nvidia code. The XCB guys have a handle on that one, and think they can patch XCB itself to work around it, so hopefully that's a non-issue. Finally, some number of users have reported major performance degredation using XCB in some configurations. The XCB guys were actively going after that bug as well yesterday, so hopefully that'll be resolved soon too.

So that's where we're at. The server is looking good, and thanks to Julien and Drew Parsons we've got the latest X server release candidate and new drivers sitting in experimental, complete with the new (intel-only right now) randr 1.2 hotness, so if you want it, you know where to get it. I've finally begun my small contributions to the having a fully automagic configuring X server in experimental as well, but I'll blog about that when I reach my first milestone.

Today is such a wonderful day! Congratulations to everyone in the project who made the release possible, and a special thank you to the release team for the heroic effort!

Anyone in Boston/Cambridge who's considering coming out to the last-minute release party tonight should just go for it. It's a big day and we should celebrate it!

There's been a ton of blog spew about FizzBuzz. My two favorites are from the always excellent Raganwald and Giles Bowkett. I waited until after the furor was over (at least, I hope it's over now) to post this, because a lot of the criticism of the FizzBuzz madness is spot on.

I think one of the neat things to fall out of it all that people seem to have ignored is that FizzBuzz provides an incredibly simple framework with which to play with essentially any language feature you want. Sure, the problem is trivial to implement, but that's the beauty of it. You can wrap up your simple solution in absurdly complicated structures in order to play with the more advanced features of the language. In this way, the problem gets out of your way and lets you focus on the language or toolkit.

I used it to play with some of Ruby's more functional aspects, for example, because I didn't feel like coding a more complicated app just for that. Sure, people are doing things like showing off how much java they can code around this little problem, and I don't think there's any value in that at all. But FizzBuzz does provide a surprisingly useful set of training wheels for diving in to new aspects of whatever you're working on. Note that FizzBuzz doesn't provide any real advantage over implementing something like a quicksort here, but that doesn't really diminish it either.

This article got me thinking about some new ways we could dramatically improve Debian. We had a lot of success in the past because good packaging helps people get over the fearful hump of installing and setting up new software in order to learn it. We're great at that, and the battle is pretty much over there.

Afterwards though, I don't think we're so good at helping our users through the scary parts. We include a lot of documentation, but that's not really cutting it any more. I set out to work on X because the scariest thing for a lot of users is getting X up and running, and I wanted to help them (and myself!) do it. We still don't have that nailed, but it's in the pipeline, so I think the next stage will be to help people do cool things with X that they wouldn't have done before. In the past, this would have involved doing things like setting xrdb settings, but these days such things aren't really useful. I'm going to continue brainstorming this, but to this end I've started a page on the wiki that's expressly for helping users get over some of the more difficult and interesting things that people might want to do with, or to, X.

Currently the only tip is on building packages using upstream's git HEAD and our own packaging, but I'm looking to put more stuff up in the nearish future. While we haven't been maintaining it so well, the XSF FAQ has a lot of these sorts of tips too.

I think we can push harder and be more clever about giving our users and ourselves cool things to do with Debian beyond packaging. The XSF move to git opened up the opportunity to easily track the X.org HEAD with the Debian packaging, and I think that sort of thing is indicative that we can be clever about enabling people at all stages of the development process, not just through the packaging itself. If you guys have any ideas for more X tips you'd like to see documented, please edit that wiki page or at least drop me or debian-x a mail so we can write it up for you. I want to see how far we can push this.

I was away in Philadelphia over the past week for the annual Drosophila meeting. My boss presented our work, and I shared a poster about it with the postdoc in the lab. I was constantly running from talk to talk and from poster to poster, trying to soak up as much as I could. I also got to meet a fair number of famous people, which was pretty awesome. It's not every day you get to meet a Nobel laureate, but that's why you go to these things. We got a lot of good feedback on our work, and we've basically gone in to overdrive to try and get the paper (which will be my first one) submitted.

Since I've been back, I haven't had any significant time to do Debian work, mainly because I've been in the lab or just taking care of life stuff almost non-stop. I managed to sneak in some time to tweak the XSF wiki pages, but the rest of the team has been handling things in my absence. I wish I could report on what they've been up to, but I haven't looked at any non-personal email for the past week.

Finally having a chance to check planet Debian today, I'm excited to see Martin's various posts about the release management for different free software projects. Obviously that's been the major thorn in our side for a while now, and while we're improving we can obviously do better. I'm looking forward to a post-mortem report and discussion from the release team about what the next steps we need to take are. I have my own ideas of course, but the release team has a much wider field of view than I've been able to achieve.

Off to see the Shins tonight, hopefully they're as good live as I've heard.

Julien Cristau and I have finished putting Xorg 7.2 in to experimental, so have at it! Julien did most of the work on this release, including the server and libs. The transition to git appears to be paying off already, as we're all moving towards running the bleeding edge stuff mainly because it's so easy to do now. This should give us the ability to take a more active role in upstream development. I've already sorta taken on responsibility for some of the upstream documentation (don't ask me how that happened) but now that things are moving I'll be looking to do work in the code as well. I wouldn't be surprised if other XSF members start to do the same.

ImageJ is probably the coolest piece of Free Software that the Free Software community isn't broadly aware of yet. It's a stable, mature piece of cross-platform code that supports both plugins and macros, and a large number of these have already been written by the scientific community. When contrasted to the photoshop/gimp debates, there simply is no competitor to ImageJ in the world of biological imaging: it's the standard for such work (except for specialized tasks like driving microscopes). If it wasn't in java (which I don't really know the tools for right now) I'd have uploaded it to Debian long ago.

A word of note though: if you want to use it seriously, I recommend building it yourself. I just spent two hours reading through the interpreter trying to speed up an extremely slow macro only to find that with a simple rebuild with the jdk in unstable's non-free I got an immediate and more than acceptable speedup, which should speed up my PhD work significantly. Still, the code is relatively nice and it was fun digging in to the interpreter, which was quite easy to understand. I may have to add a few more macro functions that I've been itching to have.

With the recent freeing of java, it'll be great to see software like imagej and jedit (which I'm also really enjoying) enter Debian finally.

Today, thanks to Julien Cristau's and David Nusinow's patience, I've been able to do my first "commit" to the XSF git repository, for the best benefit of French-speaking Canadian users (whether or not they do support Quebec autonomy), fixing #408482. So, I should officially declare myself as a deep hacker from now. Watch your back...

For several months now, the XSF has been discussing, planning, and preparing to move from our old reliable svn repository to our new distributed git repositories on git.debian.org. As of a few minutes ago, that move is complete.

I'd like to thank the Alioth admins for setting up git.debian.org and letting us hammer it with the whole xorg codebase. Also deserving the lion's share of the credit for this move is Thierry Reding, who wrote the infrastructure and did a lot of debugging of the conversion script that came with git to let us make this move. It was a huge task, and I'm still amazed at how quickly he managed to pull it off.

I'm really excited that this is finally done. I've been wanting to have our codebase in some sort of distributed system ever since I started working on xorg a while back. Because I was deriving packages from Ubuntu, who was in turn deriving packages from us, it seemed like having the whole thing in a distributed system would have made my life a lot easier. It would also potentially make it easier on other derivatives who customize the X packages, like Knoppix. For a while I thought we were going to move to mercurial, but once X.org itself moved to git, it only made sense to follow suit. I'm excited at the benefits that this move will provide us, which will hopefully translate to faster updates and higher quality packages for Debian users. And this is only the beginning of what's going to come during the Lenny release cycle.

This has been a little overdue, but here it is. Lots of less than glamorous stuff has been going on in the XSF, and a few more exciting things are in the pipeline.

Among the less glamorous stuff, our resident release junkie/alpha porter, Steve Langasek, fixed #392500 which was our major RC bug on the alpha arch. Aside from that bug, there's been a whole host of bug triage by our newest team member, Brice Goglin. Brice has taken on the unenviable task of going through the massive list of bugs owned by the XSF. I've been traditionally less than responsible about handling bug reports like I should, and Brice is dealing with the mess I've left behind. Before he started, we were at over 2000 outstanding bugs, and as of this writing we're down to 1646 bugs, which is a huge amount of work. Hopefully this will go a long way towards making our little corner of the BTS usable for mere mortals. Aside from that, there's been an enormous amount of small cleanups and bug fixes by the whole team, most notably Julien Cristau (who's been doing more actual release management than yours truly), Thierry Redding, and Drew Parsons. Perhaps most important among these are miscellaneous last minute driver fixes that will enable a fair number of people to actually run Etch without backports. Michel D nzer has continued to be his usual awesome self, responding to the tough DRI bugs that the rest of us are terrified to approach.

Some of the more exciting stuff from a user perspective has been the various updates and new packaging going on. Thierry has taken on mesa, which is an incredibly daunting task, and he's done and incredible job of it so far. He and Julien cooperated on getting the newest mesa release, 6.5.2, in to experimental. That's a huge step on the way to getting the 7.2 release in to the archive. Thierry has also packaged up the newest compiz and some additional plugins ported from beryl, both of which are waiting in NEW right now for our overworked ftp masters to find time to have a look at them. Speaking of beryl, we also have that more or less complete and packaged. Our second-newest XSF member, Shawn Starr, has taken on beryl, and done a great job of getting the packages ready for experimental. They came back from review with a few minor comments, so he's busy getting those last issues resolved, so beryl should be winging its way over to NEW again for re-review soon. Finally, Josh Triplett and Jamie Sharp, who are both Debian and XCB developers, have put XCB in to experimental for you to test and play with. Expect to hear more about this when the Lenny development cycle starts.

The other huge thing that's been going on, and what I've been devoting most of my time to (aside from reading all the mail from Brice's bug triage), is transitioning the XSF over to git. Thierry has written major chunk of infrastructure to help move us over. I've done most of the conversion locally, and have been putting things up on git.debian.org as I go. As of now, we've got a very large chunk of X in git now, and using svn for those bits is officially closed. I'm hoping to complete the move in the next two weeks or so. If you want the above software that's not yet in the archive (beryl, compiz, compiz-extra, etc) you can clone it from the git repositories and build away. The other major thing that I've been doing is writing up a XSF git policy. This required a lot of input from the team, and we had to come up with a reasonable way of working the archive so that we could easily work with an upstream that was also using git, which as far as I know is a unique situation right now. It's in pretty good shape right now and we're just starting to put it in to real use. I've proposed a talk for Debconf on the XSF roadmap for Lenny, and I'll be sure to talk about our experiences using git if it gets accepted. In addition, we've all been learning the ins and outs of git, which is a whole other post in itself. I think that the XSF will end up being a really good resource for people in Debian who are looking to use git, as we'll have a lot of real world experience with a tool that relatively few people actually seem to know. Since I think git usage will only grow in the future, hopefully this will end up being valuable for Debian as a whole.

liw's latest blog post got me thinking again about our apt frontends. I've never been satisfied with them, and I've found synaptic particularly unwieldy. They get the job done just fine, but I haven't been able to figure out a better way to do it.

Looking back though, I think there's only one real answer: we want an apt frontend that's just like this. You just search for what you want, mark the packages that show up to be installed or removed, and then just run the thing. Our current setup isn't too different from ye olde web directories (remember when you found links on yahoo or dmoz by drilling down through hand-sorted categories?) which mercifully died in favor of a simple text box and submit button. I think our current apt frontends need to do the same.

Lately I keep seeing people talking about a "crisis" in the ruby community due to the fact that rubinius, jruby, and YARV are all being written. There seems to be some subtle hand-wringing under the covers about divergence between these implementations. The ruby language is in pretty solid form, with a few little problems that should be cleaned up for the 2.0 release, so I don't think it's very likely that any divergence will be particularly damaging.

More importantly though, I think it's a sign that ruby is alive and well, given that there's three different projects that are working to provide an improved implementation for a language that was largely ignored until two or three years ago. Plus the benchmarks for YARV (which was just merged to the ruby trunk) look pretty hot.

Unfortunately for the doomsayers, most of what I've heard and read from the actual ruby community about all three of these projects has been a giant ball of excitement. I think it's really sweet that we'll have ruby running on the JVM, on a sexy Smalltalk style VM, and also a significantly sped up classic interpreter. Now all I want for Christmas is more time to actually write the rails site that's been pounding away inside my head like Athena.

I spent some time playing with haskell over the past month or so. One of the most incredible things about it is the wonderful community that has sprung up around the language. The haskell homepage is a treasure trove of information, excited users throw all sorts of new articles at reddit every day, and the #haskell channel is exactly what you want out of an irc channel. A nice bonus for Debian types is the incredibly close ties the haskell community has with our distro.

Comparing this to Debian is instructive. The haskell community seems to be having a ton of fun using their language. The sense in #debian, or from whatever Debian tutorials I read, is that people aren't using their system to have fun any more. The air of joy and occasional whimsy that traces its way through #haskell (and also very strongly through the ruby community) seems to be somewhat surpressed in Debian, as though we're so big and cool and technically competent that we don't have time for frivolity. It's hard to have fun and create a warm and inviting community with this kind of attitude. Turf wars, protocol, and politics only compound the problem.

Doing something fun for its own sake should be a part of the Debian experience the same way that it's inherently part of the free software experience. It's way too easy to lose that in the mountain of packages, emails, and bug reports. Using Debian makes me happy, and I want to try and let that spirit out to play a little more.

I love that one of the benefits to working on free software is that it exposes you to tools that you wouldn't normally be aware of. A prime example is software that you can use for writing documentation, like LaTeX and revision control systems. At work I've been writing up a fairly long document. Normally at work I'm forced to use OO.o or word because I have to trade the file back and forth with my boss, but this time since I'm doing all the actual writing, I've been using LaTeX and git to manage the thing. In addition, I need a bibliography and references, so I basically needed something like LaTeX. I send my boss an rtf (made with latex2rtf) and pdf (made with pdflatex) when I want comments, and I can still use the highly structured style of LaTeX to make sure that things like my lists get formatted properly every single time. Trying to do this in Word was both frustrating and time consuming.

The best part about the experience has been using revision control though. Having atomic changesets with a log message is something we tend to take for granted in free software work, but compare it to the change tracking in OO.o and Word. It's amazing how much easier it makes it. I can actually see what I was thinking a few days ago, which was the last time I had been revising the document. Being able to visualize the changes and history with tools like qgit are even nicer. And tags... I don't think OO.o or Word lets you tag specific revisions, but I know that when I do this with Word, I end up with a ton of documents labeled "DavidRev1" and so forth, and I always mess up the revisions by using "Save" instead of "Save As".

And this doesn't even touch on the things I haven't done yet. I haven't done any branching, for example. I'm sure that when I write my thesis, I'll end up using that, but just knowing that it's available is exciting. The thing I wish I could do most though is actually put the repo up somewhere and have me and my boss actually use it the same way a normal shared source code repository is used.

The standard sorry ending to this story is that getting these things in broad use is basically a pipe dream. It continually amazes me that people will put up with Word or Powerpoint when it's so often the wrong tool for the job. The simplest things, like being able to look at a document's history and the diff and know in a minute exactly what you were thinking when you put down your work a week ago, help so much. It's sad because the technology problem has been largely solved (a small GUI frontend would be the last piece), but the evangelism problem remains. One thing is for sure, I'm not looking forward to writing my next paper in Word.

I'm finally done with this intense histology class I've been taking over the past few weeks. I haven't had nearly as much time to focus on real dedicated Debian work, so I've been largely reduced to sponsoring the killer work done by other XSF members and distracting my brain a little by trying to wrap it around haskell. At this point I can tell you the difference between different parts of the testes at a cellular level, and how your lung and liver compare. Thrilling stuff, I know.

Tonight my plan is to drink heavily to celebrate the end of this insane brush with medical school. Tomorrow I'll work off the hangover by writing up requests to get a few last minute bugfixes approved for etch, hopefully followed by moving all of the XSF repos over to git, since Thierry appears to have worked out all the major bugs with our svn->git conversion scripts. It's a strange feeling, hovering between infrastructures, and I'll be glad to have it finished so I can move on to hacking our current packaging to little tiny bits.

Sven, when a prominent DD gets busy in his personal life, we don't say that his personal life is trying to kill Debian. Similarly, when a prominent DD gets hired somewhere and gets very busy and he doesn't have as much time for Debian, we don't say that the employer is trying to kill Debian. The same should be true when that employer is Canonical.

With all the talk about binary drivers, and Ubuntu's recent decision to ship them by default, I was going to try and rant or philosophize about the various issues it raises, and how I think ripping Ubuntu a new one for this move is justified, but instead I'm going to talk about kitties and happy things.

On the XSF front, the coolest news has come from people other than me. In addition to providing compiz updates and improvements, Thierry Reding has been busy cleaning up the Debian mesa packaging in the XSF repo. Mesa's Debian maintainer hasn't been very active over the past few months, so Thierry has stepped in to help out there.

Julien Cristau, who helped in the early work moving from XFree86 to Xorg, has returned to the XSF to take over maintainance of xterm, which I've almost completely neglected. Both these packages needed more dedicated maintainance than I could provide, and it's great to see them both being beaten in to shape.

Drew Parsons has been as industrious as ever, packaging updates for drivers so we can ship Etch with driver support that is very close to what will be released upstream as 7.2. In addition, he's packaged the modesetting branch of the i810 driver. This is an experimental development branch that will become the mainline in the nearish future, and it basically allows the driver to set modelines that aren't specified by the BIOS, just like other drivers.

Christian Perrier continues to rock the translations.

I've been doing unglamorous work bringing the Xorg docs in to the late 90's, thus making sure that we ship with docs so that users can tell what's on their systems.

Finally, Thierry has put a ton of work in building infrastructure to move the XSF svn repo over to git. I've been evaluating this, and hopefully we can make the move soon so that we hit etch+1 development running. Using git will provide an easier means of pulling from and pushing to upstream. Hopefully, downstream derivatives will also use git as well to facilitate this. I'm really excited about all of this because it feels like we're active across the board.

And now for the kitties. Nicole and I have adopted a cat. We get to take her home from the shelter next Wednesday, so if some random characters start to appear from me on irc, it's probably her fault. Rest assured that when I never run for DPL, she will be a far better running mate than Zeke. As a favor I would like to ask you, all my loyal readers: if I start to talk about my cat constantly, like one would one's own child, please punch me in the kidney. Thank you.

All the browser/mail client renaming debate aside, klowner did an absolutely fantastic job with his proposed iceweasel icon, and I'm really hoping that this one gets adopted by our maintainers. Hopefully he'll do a similar one for icedove. To be honest, I like this icon better than the official firefox one.

Thanks to David Nusinow, Thierry Reding, Kristian H gsberg and Michel D nzer to have made this possible. It’s really nice looking, but damn, this is soooooooooooooo slooooooooooow. I already tweaked my X configuration, so that GL applications would be fluid, and they are, but compiz is so much slower than all the rest of the GL applications that I really wonder what’s going on. Is it so much more difficult to display 3 windows than to display the full earth with plenty of textures ? As a bonus, for an unknown reason, it cuts the nautilus desktop window at a width of 1024 instead of 1280., which makes the right of the screen a warp zone… (For the record, I have a Radeon Mobility 9200 with the x.org drivers ; I should try with the proprietary ones) Update : The slowness might be related to this message:
libGL warning: 3D driver claims to not support visual 0x4b Update 2 : According to this comment from Michel D nzer, the above message is only cosmetic.
I solved my slowness problem ! I just needed to switch back to XAA instead of EXA as an acceleration method (Option “AccelMethod”). There still remains the geometry problem… even fullscreened windows are limited to a width of 1024, though the gnome panel is correctly at the right-most of the screen (I use a vertical panel on the right of the screen).
There is also a cosmetic problem when switching from “normal” use to GL use (like cube rotation, window moving with wobbly, etc.): the window contents are kind of blured, but there’s nothing we can do about that, except have the windows blured in the same way in the first place.
Ah, and scrolling in windows is more sluggish, now. Update 3 : After some tracing of compiz, and some reading of the source code, it appears that the width limit problem is indeed due, as suggested by Hez in the comments, to GL_MAX_TEXTURE_SIZE being 1024 (you can display it with glxinfo -l grep GL_MAX_TEXTURE_SIZE). I wonder if, as suggested by erich, there is really an environment variable to change that…